Mobile-compatible offering of commercially identical items for post-retail sale

ABSTRACT

Systems, methods, and apparatuses for mobile-compatible offering of commercially identical items for post-retail sale are described herein. A mobile application may be used to pair with a point-of-sale system and to record an availability of units from a retail package. The mobile application may receive information indicating a current location of the mobile device and select, based on the indicated location, a point-of-sale system. The mobile application may send information that identifies the mobile application to the point-of-sale system. The mobile application may receive an indication of a retail package that includes a plurality of commercially identical items and an indication of a quantity of the commercially identical items that a user wishes to purchase.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.14/845,160, filed on Sep. 3, 2015, which is incorporated by referenceherein in its entirety.

BACKGROUND

Aspects of the disclosure relate in general to mobile datacommunications and support for post-retail sales.

DESCRIPTION OF THE RELATED ART

The recent and widespread availability of mobile interconnectivity hassupported the rise of a sharing economy. One example of this trend isthe Uber mobile app, which allows vehicle owners to capitalize on unusedcapacity of their vehicles. Another example is the Airbnb mobile app,which allows homeowners and apartment renters to capitalize on unusedcapacity of their residences. Thus far, however, such mobile-readycapitalization has been limited to shared use of large investments.

SUMMARY

A method, according to a general configuration, of pairing a mobile appwith a point-of-sale system and recording an availability of units froma retail package is described. This method includes receivinginformation indicating a current location of a mobile device; based onthe indicated location, selecting a point-of-sale (POS) system;transmitting, to the selected POS system, information that identifies amobile app resident on the mobile device; receiving, from at least oneamong the POS system and the mobile device, an indication of a retailpackage that includes a plurality of commercially identical items; andreceiving, from the mobile app resident on the mobile device, anindication of a quantity of the commercially identical items. A middlelayer configured to perform such a method is also disclosed.Computer-readable storage media (e.g., non-transitory media) havinginstructions that cause one or more processors executing theinstructions to perform such a method are also disclosed.

An apparatus, according to a general configuration, for pairing a mobileapp with a point-of-sale system and recording an availability of unitsfrom a retail package is described. The apparatus includes a pairingservice configured to receive information indicating a current locationof a mobile device; to select, based on the indicated location, apoint-of-sale (POS) system; and to transmit, to the selected POS system,information that identifies a mobile app resident on the mobile device.The apparatus also includes a transaction data exchange serviceconfigured to receive, from at least one among the POS system and themobile device, an indication of a retail package that includes aplurality of commercially identical items; and to receive, from themobile app resident on the mobile device, an indication of a quantity ofthe commercially identical items.

A method, according to another general configuration, of using a mobiledevice to purchase a retail package and to update an inventory thatindicates subunits of the retail package is described. This methodincludes using a mobile device to transmit payment information for atransaction to a point-of-sale system; using the mobile device toreceive purchase information for the transaction from the point-of-salesystem that identifies a retail package purchased in the transaction,the retail package including a plurality of commercially identicalitems; using the mobile device to select a quantity of the commerciallyidentical items of the retail package; and using the mobile device totransmit a command to update an inventory associated with the mobiledevice to include the selected quantity of the commercially identicalitems. A mobile device configured to perform such a method is alsodisclosed. Computer-readable storage media (e.g., non-transitory media)having instructions that cause one or more processors executing theinstructions to perform such a method are also disclosed.

An apparatus, according to another general configuration, for purchasinga retail package and updating an inventory that indicates subunits ofthe retail package is described. The apparatus includes a digital walletconfigured to transmit payment information for a transaction to apoint-of-sale system. The apparatus also includes a mobile appconfigured to receive purchase information for the transaction from thepoint-of-sale system that identifies a retail package purchased in thetransaction, the retail package including a plurality of commerciallyidentical items; to select a quantity of the commercially identicalitems of the retail package; and to transmit a command to update aninventory associated with the mobile device to include the selectedquantity of the commercially identical items.

A method, according to another general configuration, of maintaining aninventory of items and corresponding providers and of responding tocustomer requests relating to the items is described. This methodincludes receiving a first text message, from a first subscriber number,that identifies a provider, an item, and a quantity of commerciallyidentical units within the item; receiving a second text message, from asecond subscriber number, that indicates a request relating to the item;and transmitting, to the second subscriber number, a response to therequest. A system configured to perform such a method is also disclosed.Computer-readable storage media (e.g., non-transitory media) havinginstructions that cause one or more processors executing theinstructions to perform such a method are also disclosed.

An apparatus, according to another general configuration, formaintaining an inventory of items and corresponding providers and ofresponding to customer requests relating to the items is described. Theapparatus includes a database management service configured to update aninventory in response to receiving a first text message, from a firstsubscriber number, that identifies a provider, an item, and a quantityof commercially identical units within the item. The apparatus alsoincludes an interface configured to transmit to a second subscribernumber, in response to receiving a second text message, from the secondsubscriber number, that indicates a request relating to the item, aresponse to the request.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows a flowchart of a method MA100 of pairing a mobile app witha point-of-sale system and recording an availability of sub-units of apurchased retail package.

FIGS. 1B and 1C show diagrams of exchanges of data among a mobile app, amiddle layer, and a POS system.

FIG. 2 includes a block diagram of an implementation ML110 of middlelayer ML100.

FIG. 3A shows an example of an entry in an implementation of POS systemdatabase SDB100.

FIG. 3B shows an application of an implementation XSV110 of serviceXSV100.

FIG. 3C shows an application of an implementation IFC110 of interfaceIFC100.

FIG. 4 shows a block diagram of an implementation POS110 of POS systemPOS100.

FIG. 5A shows a flowchart for a method MB100 of using a mobile device topurchase a retail package and to update an inventory to include itemswithin the retail package.

FIG. 5B shows a diagram of exchanges of data among a mobile app, a POSsystem, and a middle layer.

FIG. 6 shows a block diagram of an implementation MOD110 of mobiledevice MOD100.

FIG. 7A shows a flowchart of a method MC100 of maintaining an inventoryof items and corresponding providers and of responding to customerrequests relating to the items.

FIG. 7B shows a diagram of exchanges of data among a provider subscribernumber, a middle layer, and a customer subscriber number.

DETAILED DESCRIPTION

Many products are packaged for retail purchase (e.g., by an end-userconsumer) as a bulk package that includes a number of commerciallyidentical units but is identified as a single item for retail purchase.One example of such a bulk package is a bottle or other container ofpills. In other cases, a retail package may contain a number ofcommercially identical items that are packed individually in bags orother wrappers. Examples of such packages include a package of six,twelve, or twenty-four cans of soda; a box of ten bags of microwavepopcorn; and a box of twelve packages of instant ramen noodles.

Such a bulk package is typically tagged with a single instance of acorresponding retail tracking identifier (e.g., a Universal Product Code(UPC) barcode or radio-frequency identification (RFID) item-level tag)for the package. The individual component units may bear identifyinginformation (e.g., name) and/or other information such as expirationdate (e.g., on a contraceptive wrapper), but typically lack any suchretail tracking identifier.

Such bulk packaging may be found among personal care products, includingover-the-counter medications, feminine hygiene products, andnon-prescription contraceptives. Examples of over-the-countermedications may include pain relievers (e.g., aspirin, ibuprofen,acetaminophen (also called paracetamol)), laxatives, antidiarrheals,decongestants, antihistamines, and cough suppressors (e.g., coughdrops). Such medications may be retail packaged, for example, as abottle or other container of pills or as a blister pack having one ormore pills in each compartment. Examples of feminine hygiene productsmay include tampons and sanitary napkins (also called sanitary pads ormenstrual pads). Examples of non-prescription contraceptives may includecondoms and contraceptive sponges. Other examples of bulk packagedpersonal care products include absorbent products (such as diapers andincontinence products), adhesive bandages, and oral hygiene products(e.g., dental flossers).

The marginal cost of each component unit within such a bulk package willtypically decrease as the number of units in the package increases. Forexample, the cost per pill (e.g., tablet or capsule) in a bottle of anover-the-counter medication (e.g., a pain reliever) will typically bemuch less for a bottle of one hundred pills than for a bottle oftwenty-four pills. Nevertheless, purchase of the larger package mayrepresent a significant one-time expense for the consumer. Moreover, theproduct will commonly have an expiration date (especially for foodstuffsand medications). For a retail purchaser who uses the product onlyoccasionally, the initial potential savings may evaporate or even bereversed if the product expires before all of its units are consumed.

Systems and methods as described herein may be used to support resale ofsuch unused capacity to other consumers. Such resale may reduce riskassociated with the initial capital outlay and/or increase availabilityof the product within a corresponding population. Particularcontemplated applications include dense populations of people having asimilar demand for the product (e.g., a college dormitory or similarresidential compound) and clustered populations that may be too small tosupport a traditional retail presence (e.g., a village in a developingeconomy).

Leveraging the availability of smartphones and/or feature phones, anecosystem may be created for people to buy over-the-counter medications,oral hygiene, feminine hygiene, contraceptive, and/or other personalcare products from other individuals on-demand and/or in an emergencysituation. Such practice may help to reduce wastage of products that arepredominantly sold in bulk and might not be consumed by the customerentirely before expiring.

It may be desired to provide a system to enable anyone with a smartphoneto manually scan and upload a stock of over-the-counter medications andquantities, using a mobile app and/or a web portal.

Additionally or in the alternative to such manual loading of products bya user provider to the online inventory, an automated process may becreated to add products to the user's online inventory at the time ofcheckout when the user purchases items at the store. This scenario maybe enabled, for example, by using a middle layer that can integrate withdifferent POS systems present at both large medical stores as well asgeneral retail stores, for over-the-counter medications and/or otherpersonal care products.

FIG. 1A shows a flowchart of a method MA100 of pairing a mobile app witha point-of-sale system and recording an availability of units from aretail package. Such a method may be performed, for example, by a middlelayer as described below.

Method MA100 includes tasks TA100, TA200, TA300, and TA400. Task TA100receives information indicating a current location of a mobile device.In one example, the location is in the form of GPS coordinates. In atypical implementation, task TA100 receives the location information viaone or more data networks, such as one or more cellular data networks(e.g., 2G, 3G, 4G, LTE, etc.) and/or one or more local- and/or wide-areawireless data networks (e.g., IEEE 802.11 or WiFi).

Based on the indicated location, task TA200 selects a point-of-sale(POS) system. For example, task TA200 may be implemented to select, fromamong a plurality of POS systems whose locations are known, the POSsystem closest to the indicated location. The known location of a POSsystem may be recorded as a location (e.g., in GPS coordinates) of aretail establishment at which the POS system is found. The plurality ofPOS systems may be limited to POS systems of a particular retailer ormay include POS systems of a plurality of retailers. For example, taskTA200 may be implemented to select a POS system of a retailer only ifthe mobile device is currently associated with an account of a loyaltyprogram of the retailer. Such an association may be recorded, forexample, in a database entry that corresponds to the mobile device(e.g., a corresponding entry of an implementation of provider databaseVDB100 as described below).

Task TA300 transmits, to the selected point-of-sale system, informationthat identifies a mobile app which is resident on the mobile device.Such information distinguishes the mobile app from other instances ofthe same software that may be resident on other mobile devices. Theinformation may be a label that identifies, for example, a particularpayment account (e.g., a credit card account number), or a particularaccount of a loyalty program of a retailer (e.g., the retailerassociated with the selected POS system), where the particular accounthas already been associated with the mobile app. The POS system may beconfigured to use such information to associate a particular transactionwith the mobile application so that information relating to thetransaction (e.g., a receipt) may be directed to the mobile application.Task TA300 may be included within an activity of pairing the mobile appand the POS system (e.g., as described herein with reference to pairingservice PSV100).

Task TA400 receives, from at least one among the POS system and themobile device, an indicator of a retail package that includes aplurality of commercially identical items. The receipt of this indicator(e.g., the name and/or product code of the retail package) typicallyindicates that the mobile app has been used to purchase the retailpackage via the POS system. If the package indicator is received fromthe POS system, task TA400 may include forwarding the package indicatorto the mobile app. Alternatively, the POS system may be configured tosend the package indicator directly to the mobile app (e.g., via SMS, orto an e-mail address or URL associated with the mobile app), such asincluded in a receipt for the transaction, in which case task TA400 maythen receive the package indicator from the mobile app.

Task TA500 receives, from the mobile app resident on the mobile device,an indication of a quantity of the commercially identical items. Theindicated quantity may be entered by the user as, for example, a numberof the commercially identical items, or a proportion of the totalquantity of the commercially identical items in the retail package.Alternatively, the indicated quantity may be such a quantity that wassuggested to the user (e.g., by or via the mobile app) and accepted bythe user via the mobile app.

FIGS. 1B and 1C show diagrams of exchanges of data among a mobile app, amiddle layer, and a POS system, in examples of uses of method MA100 asdescribed above. First, the middle layer receives from the mobile appinformation indicating a current location of a mobile device on whichthe mobile app is resident. The middle layer then transmits, to aselected POS system, information that identifies the mobile app. Themiddle layer receives, from at least one among the POS system (FIG. 1B)and the mobile device (FIG. 1C), an indicator of a retail package thatincludes a plurality of commercially identical items. The middle layeralso receives, from the mobile app, an indication of a quantity of thecommercially identical items.

A middle layer ML100 may be used to perform method MA100. Such a middlelayer may comprise software executing on one or more processors, usingdata stored in one or more storage elements (e.g., random-access memory,disk storage, etc.). For example, middle layer ML100 may includesoftware components (e.g., services) executing on one or more serversand configured to receive data from one or more databases and/or tocommunicate with one or more data networks (e.g., via appropriateinterfaces).

FIG. 2 includes a block diagram of an implementation ML110 of middlelayer ML100 that includes a pairing service PSV100 and a transactiondata exchange service XSV100. From mobile app MAP100, pairing servicePSV100 receives an identifier of the mobile app MAI100 and a location ofthe mobile app MAL100. Identifier MAI100 may be a label identifying aparticular payment account (e.g., a credit card account number), aparticular account of a particular retailer loyalty program, etc.Location MAL100 may be a label that indicates a current location (e.g.,in GPS coordinates) of a mobile device upon which mobile app MAP100 isexecuting. Such data communication between mobile app MAP100 and middlelayer ML100 may occur, for example, over one or more cellular datanetworks (e.g., 2G, 3G, 4G, LTE, etc.) and/or one or more local- and/orwide-area wireless data networks (e.g., IEEE 802.11 or WiFi). Such datacommunication between mobile app MAP100 and middle layer ML100 mayoccur, for example, via an interface IFC100 that may perform operationssuch as formatting, handshaking, etc.

Based on location MAL100, middle layer ML100 selects one among aplurality of POS systems. In one example, pairing service PSV100 isconfigured to use information from a database SDB100 that stores thelocations of the POS systems (e.g., in GPS coordinates) to select a POSsystem that is within a threshold distance of location MAL100. It may bedesirable to design the threshold distance to exclude transientsituations, such as a user of the mobile device driving or walking pasta POS system. For example, different threshold distances may beassociated with different POS systems (e.g., a smaller thresholddistance for a POS system in a store located along an urban street thanfor a POS system in a store along a rural highway). Additionally oralternatively, pairing service PSV100 may be implemented to select a POSsystem only after determining that a detection condition has persistedover a particular time period (e.g., two, four, five, eight, ten,fifteen, or sixteen seconds). Examples of such a threshold distanceinclude two, four, five, eight, ten, twelve, sixteen, twenty, andthirty-two feet and one, two, four, five, eight, ten, twelve, andsixteen meters.

The plurality of POS systems may be limited to POS systems of aparticular retailer or may include POS systems of a plurality ofretailers. For example, pairing service PSV100 may be implemented toselect a POS system of a retailer only if the mobile device is currentlyassociated with an account of a loyalty program of the retailer. Such anassociation may be recorded, for example, in a corresponding entry of aprovider database VDB100 that indicates whether the mobile device isassociated with a particular retailer loyalty program (and if so, mayindicate the account number as well).

POS systems may be configured to have closed architectures, such that aninterface capable of exchanging data with a POS system of one type maybe unable to exchange data with a POS system of another type. It may bedesirable to configure middle layer ML100 to allow data exchange withmore than one such type of POS system. As shown in FIG. 2, middle layerML110 includes a plurality n of connection points CP1 to CPn, each ofwhich may be implemented to support data exchange with a differentrespective type of POS system. In such case, preparation for use ofmiddle layer ML110 with a new POS system may include configuring the POSsystem to connect to an appropriate one of the connection points andstoring this association to POS system database SDB100. In one example,a POS system connects to the corresponding connection point through auniform resource locator (URL) associated with the connection point.

Each of connection points CP1-CPn may be implemented to include, forexample, a buffer into which data is expected to be written in aparticular format. A connection point may also include softwareconfigured to verify that incoming data is properly formatted andpossibly to return an error code to the data source in response to adetermination that the incoming data does not conform to the respectiveformat.

Database SDB100 may be implemented to associate the location of a POSsystem with an appropriate one of the n connection points CP1-CPn. FIG.3A shows an example of an entry in such an implementation of POS systemdatabase SDB100. This entry (e.g., the m-th in a total of M entries)associates the location of POS system m (e.g., in GPS coordinates) witha corresponding connection point (e.g., among connection points CP1-CPn)for POS system m. In some cases, the same connection point may beassociated with all POS systems for a particular retailer, or with allPOS systems within a particular region for a particular retailer.

Middle layer ML100 transmits, to the selected POS system, an identifierMAI200 of the mobile app. Identifier MAI200 may be the same asidentifier MAI100. Alternatively, identifier MAI200 may identify themobile app in a different context. In one such example, identifierMAI100 is a label identifying a particular payment account (e.g., acredit card account number) associated with mobile app MAP100. In thisexample, pairing service PSV100 is implemented to detect that theselected POS system is associated with a particular retailer, to useinformation from identifier MAI100 to retrieve an indication of aparticular account of the retailer's loyalty program that is associatedwith the identified payment account (e.g., from a database), and totransmit a label identifying the associated loyalty program account tothe selected POS system as identifier MAI200.

Middle layer ML110 may be implemented to select the connection pointprior to transmission of identifier MAI200. In such case, identifierMAI200 may be forwarded to the selected POS system via the appropriateconnection point. For example, pairing service PSV100 may be implementedto produce connection point selection CPS100 prior to transmission ofidentifier MAI200 (e.g., via the selected connection point).

When the mobile app associated with identifier MAI200 is used at the POSsystem for a purchase, the POS system recognizes the mobile app fromidentifier MAI200 (e.g., a label associated with the account being usedfor payment) and responds by forwarding transaction data of the purchaseto the mobile app. Such forwarding may occur once the POS system hasobtained approval for the purchase (e.g., from an issuer of a creditcard account used for the purchase). It may be desirable for the pairingbetween the POS system and the mobile app to expire after a time period(e.g., after fifteen, sixteen, thirty, thirty-two, sixty, or sixty-fourminutes) if the mobile app has not yet been presented at the POS systemfor payment. One or more of the POS system and the mobile app may alsocommunicate with one or more services of a merchant service provider(e.g., of the retailer), such as a coupon service, a loyalty programservice, and/or a payment service.

The transaction data includes information that identifies the retailpackage. Such information may include, for example, a product code suchas a corresponding 12-digit UPC-A, UPC-B, or UPC-C code; a correspondingEAN-8 or EAN-13 code; or the like. Additionally or alternatively, suchinformation may include a text description of the retail package. In oneexample, the transaction data includes a listing of the retail packageand any other retail items purchased in the transaction and theirrespective prices (e.g., a receipt). The POS system may also beconfigured to include other information within the transaction data,such as an expiration date of the package.

The POS system may be configured to forward the transaction data to themobile app by e-mail (e.g., in text format or as an attachment in text,HTML, or PDF format), by text messaging (e.g., Short Message Service or‘SMS’), or to a Uniform Resource Locator (URL) associated with themobile app. In such cases, middle layer ML100 may receive informationthat identifies the retail package from the mobile app rather than fromthe POS system (or in addition to data TXD100).

Alternatively or additionally, the POS system may forward thetransaction data to the mobile app via middle layer ML100. FIG. 2 showsone example of such forwarding in which transaction data exchangeservice XSV100 receives transaction data TXD100, via a connection pointas indicated by connection point selection CPS100, and forwards theinformation (in a possibly different form TXD200) via interface IFC100to the mobile app.

Transaction data exchange service XSV100 may be configured to filterdata TXD100 to remove extraneous information. For example, if thetransaction includes one or more items that are not to be offered forresale (e.g., a prescription medication, a single-serving beverage,etc.), transaction data exchange service XSV100 may remove informationregarding such item or items from data TXD100 to produce data TXD200. Itmay be desired to exclude from resale items that require specialhandling (e.g., storage below room temperature) to remain effective.Such filtering by service XSV100 may include comparing a list of thepurchased items to a list of items eligible for resale.

Instead of removing (e.g., by service XSV100) items that are not to beoffered for resale, it may be desired to implement interface IFC100 toflag items that are eligible for resale (e.g., by comparing a list ofthe purchased items to a list of items eligible for resale).Additionally or alternatively, mobile app MAP100 may be implemented toperform such flagging. In either case, mobile app MAP100 may beimplemented to display to the user a list of only the purchased itemswhich are eligible for resale, or to display an indication of whichitems are eligible for resale among a displayed list of all of theretail items purchased in the transaction.

Alternatively or additionally, one or more among transaction dataexchange service XSV100 and interface IFC100 may be configured toinclude additional information associated with the retail package withindata TXD200. The additional information may include such qualifiersand/or other details as, for example, brand name, manufacturer,expiration date, size, dose, barcode symbol, thumbnail image, productreview, etc. FIG. 3B shows an application of an implementation XSV110 ofservice XSV100 that is configured to use data TXD100 (e.g., a UPCproduct code) to obtain such additional information associated with theretail package from a product database PDB100. Interface IFC100 may besimilarly implemented. Additionally or alternatively, service XSV100and/or interface IFC100 may be implemented to obtain such additionalinformation through third-party application program interface (API)integration.

Service XSV100 or XSV110 and/or interface IFC100 may be implemented toinclude, within data TXD200, additional information associated with themobile app. Such information may describe a current state of aninventory associated with the mobile app (e.g., a number of the sameitem that are currently offered for resale by the user), a history ofsales from such inventory (e.g., a number of the same item that havebeen sold by the user during a recent time period, such as one, two,six, or twelve months), and/or other information that may be helpful tothe user in deciding how much of the item to offer for resale.

Middle layer ML100 receives, from the mobile app and in response to thetransaction data, an indication of a quantity of the commerciallyidentical items. In one example, this indication is a number of thecommercially identical items that a user of the mobile app wishes tooffer for resale. In another example, this indication is a proportion ofthe total quantity of commercially identical items in the retail package(e.g., twenty-five, fifty, or seventy-five percent) that a user of themobile app wishes to offer for resale. Such proportion may be based onthe user's history. For example, if the user has historically chosen tooffer fifty percent of the total quantity of pills in her purchases ofAdvil™ via the mobile app (or of ibuprofen, or of pain relievermedication), and the current purchase includes a bulk package of twentyAdvil™ pills or packets, the mobile app may suggest offering ten of theindividual items in the current purchase for resale.

FIG. 3C shows an application of an implementation IFC110 of interfaceIFC100 that is configured to use the indicated quantity to update aninventory associated with the mobile app in an inventory databaseIDB100. Interface IFC110 may also be configured to respond to requestsfrom a customer device CDV100 to purchase such an item. In this example,middle layer ML110 is also implemented to include a database managementservice DBM100 that updates database IDB100 in response to providerindications of items and quantity to be added and supportslocation—(e.g., map-) and/or category-based searches of database IDB100in response to customer queries via interface IFC110.

An implementation of method MA100 or middle layer ML100 as describedherein may be used to support post-retail resale of such commerciallyidentical units in an automated manner, triggered by conditions such asthe user's proximity to a vendor of products eligible for resale and bypurchase of a listed item, that is transparent to the user provider. Oneexample of a workflow is as follows:

1) A person using the mobile app goes to a retail store to purchase somegeneral items, as well as over-the-counter medication and femininehygiene items that he wants to add to his online inventory for resale ofindividual units. The user fills up his cart with these items andreaches the checkout counter. At the checkout counter, the POS system isconnected to a cloud-based middle-ware system (e.g., an implementationof middle layer ML100) that also connects to the mobile app. Through thecloud-based system, the mobile app notifies the POS system of itslocation. The mobile app may also have an interface to connect to thestore's loyalty system.

2) During checkout, the user taps on the mobile app to indicate that hewants to make the purchase through the mobile app and also to use themobile app to list some portion of his current purchase as available forresale. The mobile app interfaces with the POS system and completes thetransaction through an interface to a digital wallet that is alsoresident on the mobile device.

3) Post-purchase, the mobile app shows the list of items that the userhas purchased and also a suggested flag to indicate which of these itemshe would probably add to his inventory for resale. The mobile app mayalso suggest quantities of those items to be offered for resale. Forexample, if the user historically preferred to sell fifty percent of hispurchases of Advil™ through the online interface, and he currentlypurchased a retail package containing twenty individual packets ofAdvil, the mobile app may suggest uploading ten packets into the user'sinventory.

Additionally or alternatively, the mobile app may suggest a unit pricefor the items. If the purchase includes more than one commerciallydistinct package of items that may be offered for resale (e.g., apackage of Advil and a package of aspirin), the mobile app may suggest acorresponding unit price for the items in each such package. The mobileapp may suggest a unit price for the items in a bulk package based on aunit cost of the items (e.g., the purchase price of the bulk packagedivided by the number of commercially identical items in the bulkpackage).

The mobile app may be configured to calculate the unit price by applyinga markup factor to the unit cost (e.g., a factor of two or three), byadding a markup amount to the unit cost (e.g., fifty cents, one dollar,or two dollars), or by adding a markup amount after applying a markupfactor. Alternatively, the mobile app may be configured to select acorresponding one among a set of unit prices based on the unit cost. Inone such example, the mobile app selects a unit price of two dollars foritems having a unit cost of up to twenty-five cents, a unit price offour dollars for items having a unit cost of up to one dollar, and aunit price of five dollars for items having a unit cost of up to twodollars.

Alternatively, the user may indicate a unit price for the items (or acorresponding unit price for the items in each commercially distinctpackage). For a case in which the mobile app suggests a unit price, themobile app may be configured to default to the suggested unit price, orto use the suggested unit price only upon confirmation by the user, whomay choose to enter a different unit price instead.

4) Once the user has verified the selection of items and quantity (andunit price, unless a default is assigned), the user's online providerinventory may be updated accordingly. Such inventory may be stored in adatabase of the cloud-based middle-ware system (e.g., an implementationof inventory database IDB100), and such update may be performed using amanagement service of the middle-ware system (e.g., an implementation ofdatabase management service DBM100), which may also be configured toautomatically obtain details regarding the selected item such as themanufacturer and/or brand, item name, item quantity, barcode, expirydate, and/or product review, which may be obtained through third-partyAPI integration.

FIG. 4 shows a block diagram of an implementation POS110 of POS systemPOS100. In order to obtain payment information from a user of the mobiledevice (e.g., a payment card account number or other label, such as atoken associated with such a number), POS system POS110 may include anyone or more among the following: a magnetic stripe reader MSR100configured to read a magnetic stripe of a payment card (e.g., a creditcard, a debit card, a stored value card); a smartcard or card chipreader CCR100 configured to communicate (by direct physical contact orcontactlessly) with a circuit embedded in a payment card; anear-field-communications (NFC) reader NFR100 configured to communicatecontactlessly with an NFC tag and/or a mobile device (e.g., according toa standard such as ISO/IEC 18092, ECMA-340, and/or Bluetooth); and anRFID reader RFR100 configured to communicate contactlessly with an RFIDtag and/or a mobile device (e.g., according to a standard such asISO/IEC 14443 and/or ISO/IEC 18000-3). For example, POS system POS110may be configured to support any one or more of the followingcontactless payment methods: MasterCard PayPass™, American ExpressExpressPay™, Visa payWave™, Google Wallet™, and Apple Pay™. POS systemPOS110 may also include a cash drawer for handling cash transactions.

POS system POS110 may also include one or more input devices, such as ascanner SCN100 configured to read product barcodes and a keypad KB100and/or touchscreen TSC100 configured to receive user input. POS systemPOS110 may also include one or more output devices, such as a displayDSP100 and/or a receipt printer (not shown).

POS system POS110 also includes at least one controller CPU100 (e.g.,one or more microprocessors) and memory MEM100. Typical additionalcomponents not shown in FIG. 4 include an operating system, and hardwareand software interfaces configured to allow controller CPU100 and theoperating system to communicate with the various other components. POSsystem POS110 also includes a network interface NWI100 configured toreceive mobile app ID MAI200 and to transmit transaction data TXD100 viaone or more data networks, such as one or more cellular data networks(e.g., 2G, 3G, 4G, LTE, etc.) and/or one or more local- and/or wide-areawireless data networks (e.g., Bluetooth, IEEE 802.11 or WiFi).

System POS110 may be implemented to include a tablet computer. Such atablet will typically contain at least controller CPU100, memory MEM100,touchscreen TSC100, display DSP100, and network interface NWI100, witheach of one or more of the other components of system POS110 asdescribed above being integrated into the tablet or attached to such atablet (e.g., as peripherals) via a cable (e.g., a USB cable) orwirelessly (e.g., via Bluetooth).

FIG. 5A shows a flowchart for a method MB100 of using a mobile device topurchase a retail package and to update an inventory to include itemswithin the retail package. Such method may be performed, for example, bya mobile app executing on a mobile device (e.g., an implementation ofmobile app MAP100 as described above). The mobile app may be configuredto execute within a mobile operating system resident on the phone, suchas a version of Android (Google), iOS (Apple Corp.), or Windows Phone(Microsoft). It may be desirable for the mobile app to have access to alocation of the mobile device (e.g., as GPS coordinates). It may bedesirable for the mobile app to have the ability to initiate instancesof a secure payment application resident on the mobile device (e.g., adigital wallet, such as MasterPass™ (MasterCard), Google Wallet™, orApplePay™).

Method MB100 includes tasks TB100, TB200, TB300, and TB400. Task TB100uses the mobile device to transmit payment information for a transactionto a POS system. Task TB100 may be performed at a retail location. Themobile app may perform task TB100 by causing a secure paymentapplication to execute on the mobile device. For example, task TB100 mayuse the mobile device to transmit the payment information over anear-field-communication (NFC) channel. The payment information mayinclude a credit card account number or a token associated with such anaccount number.

Task TB200 uses the mobile device to receive purchase information forthe transaction that identifies a retail package, purchased in thetransaction, that includes a plurality of commercially identical itemsas described herein. Such information is produced by the POS system uponapproval of payment, and may be received by the mobile device from thePOS system or via an intermediate entity, such as a middle layer ML100as described herein. Task TB200 may include receiving the purchaseinformation over an NFC channel (e.g., the same or different than an NFCchannel used to carry the payment information), one or more cellulardata networks (e.g., 2G, 3G, 4G, LTE, etc.) and/or one or more local-and/or wide-area wireless data networks (e.g., IEEE 802.11 or WiFi).Task TB200 may include receiving the purchase information as a texte-mail, as an attachment in text, HTML, or PDF format to an e-mail, bytext messaging (e.g., SMS), or to a URL associated with the mobile app.In one example, the purchase information is the UPC product code of theretail package. In another example, the purchase information is receivedin the form of a receipt of the transaction that identifies the retailpackage (e.g., UPC product code and a brief description) and may alsoinclude the price paid for the package.

Method MB200 may also include using the mobile device to receive (e.g.,from the POS system and/or from a middle layer as described herein)other information such as any of the following: a total quantity in thepackage, a thumbnail or other image of the package and/or of theindividual items within it, a description of the product, expirationdate, etc. Such information may be retrieved, for example, by a serviceof the middle layer from an implementation of product database PDB100 asdescribed above and/or from a similar product database of the retailer(e.g., via lookup using the UPC product code and/or stock-keeping unit(SKU) number). Alternatively or additionally, method MB200 may includeusing the mobile device and the UPC product code of the retail packageto obtain such other information (e.g., via online search and/or athird-party online database).

Task TB300 uses the mobile device to select a quantity of thecommercially identical items of the retail package. As described above,the mobile app may be configured to suggest a quantity (e.g., based on ahistory of the user's activity) and/or to allow selection of thequantity as a proportion of the total quantity of individual items inthe retail package. Task TB300 may also include using the mobile deviceto select a unit price for the items. As described above, the mobile appmay be configured to suggest such a price, which may be selected bydefault. Task TB400 uses the mobile device to transmit a command toupdate an inventory associated with the user to include the selectedquantity of the commercially identical items. FIG. 5B shows a diagram ofexchanges of data among a mobile app, a POS system, and a middle layerin an example of a use of method MB100 as described above.

FIG. 6 shows a block diagram of an implementation MOD110 of mobiledevice MOD100 on which a mobile app as described herein may be resident.In order to provide payment information to a POS system, mobile deviceMOD110 may include one or more payment interfaces, such as a near-fieldradio interface NFI100 configured to communicate contactlessly with thePOS system (e.g., according to an NFC standard, such as ISO/IEC 18092,ECMA-340, and/or Bluetooth, and/or an RFID standard, such as ISO/IEC14443 and/or ISO/IEC 18000-3).

Device MOD110 includes a display DSP200 configured to provide output tothe user (e.g., as produced by the mobile app). Display DSP200 may alsobe implemented to display a QR code for presentation to the POS systemas payment information. Device MOD110 includes one or more inputdevices, such as touchscreen TSC200 and/or keypad KB200, that may beused for interacting with the mobile app, for entering a selectedquantity or proportion for resale, and/or for confirming a quantity orproportion suggested by the mobile app. Device MOD110 may include acamera CAM100 that the user may use to take a photo of the retailpackage (and/or of one or more of the individual items) to be added tothe listing for resale.

A wireless network to which device MOD110 is connected may be configuredto determine the location of the device (e.g., by cellulartriangulation, WiFi triangulation, HPS, assisted GPS, and/or anycombination of one or more such methods) and provide it to the device.Device MOD110 may then transmit this location (or a location basedthereon) as location MAL100. Additionally or alternatively, for purposesof obtaining location MAL100, mobile device MOD110 may include a GPSreceiver and antenna (not shown).

Device MOD110 also includes at least one controller CPU200 (e.g., atleast one microprocessor) configured to execute the mobile app MAP100and a memory MEM200 configured to store instructions and data of themobile app. Device MOD110 may also include a digital wallet appconfigured to execute on controller CPU200 and to provide paymentinformation (e.g., a number of a payment card account linked to thedigital wallet, or another label, such as a token associated with suchan account). Such a digital wallet app may be configured to perform acard emulation operation (e.g., host card emulation or HCE). MemoryMEM200 may also include secure storage (e.g., a secure element) tosupport such a digital wallet app. Device MOD110 may include afingerprint reader and/or other user authentication device configured toprovide authentication data to such a digital wallet app.

Mobile device MOD110 also includes a far-field radio interface FFI100configured to transmit mobile app ID MAI100 and location MAL100 and toreceive transaction data TXD200 via one or more data networks, such asone or more cellular data networks (e.g., 2G, 3G, 4G, LTE, etc.) and/orone or more local- and/or wide-area wireless data networks (e.g.,Bluetooth, IEEE 802.11 or WiFi). Typical additional components of mobiledevice MOD110 that are not shown in FIG. 6 include a mobile operatingsystem, such as a version of Android (Google), iOS (Apple Corp.), orWindows Phone (Microsoft), and hardware and software interfacesconfigured to allow controller CPU200 and the operating system tocommunicate with the various other components.

As described above, method MB100 may be performed by a mobile appexecuting on a smartphone and communicating over a broadband cellulardata network. Similarly, purchases from such an inventory may also beperformed using a mobile app, or via a web-based interface, on acustomer device CDV100 (e.g., a smartphone) communicating over abroadband cellular data network. For example, mobile app MAP100 may beimplemented to support both uploading of a provider account and purchasefrom the online inventory, with the particular user choosing to use theapp at one time to list items as a provider, and at another time tobrowse and/or purchase such items from others.

Middle layer ML100 may be implemented to support, on the customer side,a map-based search to identify one or more providers based on thecustomer's current location and the item requested. Provider databaseVDB100 may be implemented to include ratings for each provider, whichmay include an overall rating for the provider and/or a provider ratingrelating to particular categories of goods, and interface IFC100 may beimplemented to provide appropriate ratings to the customer prior topurchase. Mobile app MAP100 may be implemented to allow the customer topay for such a purchase with a payment card that is on file, such as ina digital wallet app resident on the mobile device (e.g., MasterPass).Once the purchase has been completed, the mobile app may also allow thecustomer to enter one or more ratings for the provider.

In one scenario, a student (“John”) staying at a college dormitory is indesperate need of a pain reliever (e.g., an aspirin or Advil™). Thelocal store is few miles away, but there are twenty other studentsliving in the dormitory, and there is a chance that one of them wouldhave a spare Advil™ or similar item. It is possible that John alreadyhas a box of Advil™ that has expired because he doesn't use the productvery often, and purchase of a single dosage is not available.

In this situation, interface IFC100 may be implemented to provide alocation-based search, based on John's current location, to allow Johnto search for a single (unexpired) dosage of Advil™ and to find someonenearby who has that item. Additionally he can pay directly through apayment card on file (e.g., in a digital wallet associated with themobile device, such as MasterPass). In such manner, the system couldsave John a trip to the store and also allow him to purchase medicationfor single usage rather than buying it in bulk.

Mobile app MAP100 may be implemented to support such a process bydisplaying a menu of items from which the customer may indicate herrequest. For example, the mobile app may allow the customer to select aspecific item (e.g., ibuprofen) or a category of items (e.g., painreliever). Once the selection has been made, the mobile app sends thecustomer's request and location to interface IFC100.

In response to the request, middle layer ML100 may reference providerdatabase VDB100 and inventory database IDB100 to identify at least onenearby provider (if any) that currently has the requested item, or anyitems within the requested category, within its inventory. Via interfaceIFC100, middle layer ML100 may send the names and correspondinglocations of the identified providers to the mobile app. The searchresults sent to the mobile app by middle layer ML100 may also includeother information for each corresponding provider, such as ratings, itemprices, and/or quantity available of the requested items.

The mobile app then displays the results to the customer (e.g., sortedby distance, with the closest matching provider displayed first). For acase in which the request indicated a category, the mobile app mayprepare the search results for display by breaking down results for thecategory (e.g., feminine hygiene) into results for the commerciallydistinct items within the category (e.g., tampons, sanitary napkins).

The customer then places an order by selecting, from among the displayedresults, a particular item from a particular provider. Once theselection has been made, the mobile app sends the customer's order tointerface IFC100. In response to the order, the middle layer sends anotification of the order to the provider and a confirmation of theorder to the customer. Such notification and confirmation may be sent,for example, via the mobile app, text messaging, automated voicetelephone call, and/or e-mail. The mobile app and middle layer may alsobe configured to allow the customer and provider to communicate directlyvia the middle layer (e.g., by text, audio, and/or video) if necessaryto complete the purchase. As noted above, payment by the customer may beaccomplished via a payment card on file. The middle layer may also beimplemented to send a follow-up request to the customer (e.g., via themobile app, SMS, and/or e-mail) to enter a rating for the provider.

It may be desirable to extend a system and method for resale of personalcare items in order to provide access to these important items inlocations (e.g., of developing countries) that are not penetrated bymedical retailers. Due to lack of facilities and infrastructure, forexample, providing medical solutions to rural areas in developingcountries has always been difficult. As noted above, extending supportfor such resale may also help to reduce the problem of medicationexpiration resulting from a retail availability that is limited to bulkpackaging rather than single-dose packaging.

It may be desirable to support such resale even in the absence of anetwork infrastructure as described above, such as in an area where onlyvoice calling and text messaging is available. For example, it may bedesirable to provide a similar service via text-based interaction by acustomer device (e.g., by SMS or other text messaging service), suchthat a feature phone is sufficient even if a smartphone is notavailable. Although smartphones may be scarce in developing countries,such regions typically have a deep penetration of feature phones. Forexample, in 2014 the penetration of mobile phones in India andsub-Saharan Africa was 77.58% and approximately 70%, respectively.

A cloud-based system providing such service may be implemented to allowan individual to add his or her inventory to the system using textmessaging. The system may also be implemented to support use of aweb-based platform if available. The products to be added by the usermay have been purchased at retail (e.g., via a POS system as describedabove), or online or otherwise.

The cloud-based system (e.g., an implementation of middle layer ML100)may also include a layer that organizes the personal care items bycategory and/or by the symptoms that it may be used to address. In suchone example, a customer texts that he or she has one or more particularsymptoms (e.g., a fever with dry throat). The system may be configuredto suggest medication for that ailment by identifying one or moreproducts that address such symptoms (e.g., according to a predeterminedassociation stored in an implementation of product database PDB100).Based on the customer's location, the system may identify one or moreproviders that are local to the customer (e.g., as indicated by animplementation of provider database VDB100). Such provideridentification may include performing a map-based search. The customer'slocation may have been previously entered into the system by thecustomer, may be obtained from a subscriber account associated with thecustomer's subscriber number, or may be provided by the customer in thefirst text message or in response to a text message request from thecloud-based system. It may be desired to implement method MC100 topermit a customer to indicate (e.g., within the request message or in aseparate message) a selection among multiple locations on file (e.g.,between a home location and an office location).

If a unit of the identified product is found within the inventory of alocal provider (e.g., as indicated by an implementation of inventorydatabase IDB100), the system may send a text message to the customerthat includes the contact number of at least one such provider. Themessage may also include the name of the identified item, its cost,and/or one or more ratings of each provider (e.g., an overall rating, acategory-specific rating). Such an operation of providing asymptom-based recommendation may be limited according to the geographyand/or jurisdiction of the customer's location (e.g., in order to complywith local regulations relating to practice of medicine).

The system may be configured to support cashless transactions. In oneexample, the cloud-based system is configured to allow the customer topay for the item using a mobile-phone-based money transfer service, suchas M-Pesa. Alternatively or additionally, the cloud-based system may beconfigured to allow the customer to pay for the item by drawing from aprepaid account (e.g., using a personal identification number (PIN) thatis linked to the mobile device).

FIG. 7A shows a flowchart of a method MC100 of maintaining an inventoryof items (e.g., personal care items) and corresponding providers and ofresponding to customer requests relating to the items. Such a method maybe performed, for example, by a cloud-based system (e.g., animplementation of a middle layer as described herein).

Method MC100 includes tasks TC100, TC200, and TC300. Task TC100 receivesa first text message, from a first subscriber number. A subscribernumber may be, for example, a telephone number that has been assigned bya cellular telecommunications provider to a particular mobile device(e.g., to a Subscriber Identity Module (SIM) within the device). Thefirst text message identifies a provider, an item, and a quantity ofcommercially identical units within the item. The provider may beidentified by the first subscriber number. Additional identification maybe included in the first text message and/or in a follow-up message,such as an account number and/or a personal identification number (PIN)assigned to the provider by the cloud-based service (e.g., animplementation of middle layer ML100 as described herein). The item maybe identified, for example, by a product code of the item (e.g., a UPCproduct code of a retail package). In such case, the product code may beobtained by the user by scanning or otherwise imaging the package (e.g.,using a camera of a smartphone or feature phone). Where such service isavailable, such an image of the code may be sent by the user as anattachment to the text message, for extraction of the code by thecloud-based service. The quantity may indicate a number of thecommercially identical items within the retail package and/or aproportion of the total number of such items within the package. Thefirst text message may also include a unit price for the item.Alternatively, a unit price for the item may already be stored withinthe system and/or the provider may indicate the unit price in adifferent text message that identifies the item.

Task TC200 receives a second text message, from a second subscribernumber, that indicates a request relating to the item. In one example,the request is a description of at least one symptom that is associated(e.g., within the cloud-based system) with the item. Task TC300transmits, to the second subscriber number, a response to the request.For example, the response may indicate an availability of at least oneof the commercially identical items and/or may identify the provider(e.g., may include the first subscriber number). The response may alsoinclude a unit price for the item. FIG. 7B shows a diagram of exchangesof data among a provider subscriber number, a middle layer, and acustomer subscriber number in an example of a use of method MC100 asdescribed above. Method MC100 may also be implemented to include asubsequent task TC400, which receives a third text message from thesecond subscriber number, indicating the customer's order for the item,and in response transmits a fourth text message to the first subscribernumber which notifies the provider of the customer's order.

An apparatus as disclosed herein (e.g., mobile device MOD100, POS systemPOS100, any among the elements of middle layer ML110) may be implementedin any combination of hardware with software, and/or with firmware, thatis deemed suitable for the intended application. It is noted that thevarious methods disclosed herein (e.g., any among methods MA100, MB100,and MC100) may be performed by one or more processors. Theimplementations of methods, schemes, and techniques disclosed herein(e.g., any among methods MA100, MB100, and MC100) may also be embodied,in one or more computer-readable storage media, as one or more sets ofinstructions readable and/or executable by one or more processors, suchthat the instructions cause one or more processors executing theinstructions to perform the acts of such a method as disclosed herein.Such a storage medium may be a conventional read/write memory such as amagnetic disk, floppy disk, optical disc, compact-disc read-only-memory(CD-ROM), digital versatile disc (DVD), Blu-ray Disc™, magneto-opticalstorage, flash memory, random-access memory, transistor-based memory,magnetic tape, and/or any other non-transitory computer-readable memorydevice as is known in the art for storing and retrieving data.Significantly, such computer-readable storage media may be remotelylocated from such one or more processors and may be connected to suchone or more processors via a network such as a local area network (LAN),a wide area network (WAN), or the Internet.

It is understood by those skilled in the art that instructions for suchmethod embodiments may be stored on their respective computer-readablememory and executed by their respective processors. It is understood bythose skilled in the art that other equivalent implementations can existwithout departing from the spirit or claims of the invention.

The previous description of the embodiments is provided to enable anyperson skilled in the art to practice the disclosure. The variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles defined herein may beapplied to other embodiments without the use of inventive faculty. Thus,the present disclosure is not intended to be limited to the embodimentsshown herein, but is to be accorded the widest scope consistent with theprinciples and novel features disclosed herein.

What is claimed is:
 1. A method comprising: transmitting, by a mobiledevice, payment information for a transaction to a point-of-sale system;receiving, by the mobile device, purchase information for thetransaction from the point-of-sale system that identifies a retailpackage purchased in the transaction, the retail package comprising aplurality of commercially identical items; selecting, by the mobiledevice, a quantity of the commercially identical items of the retailpackage; and transmitting, by the mobile device, a command to update aninventory associated with the mobile device to include the selectedquantity of the commercially identical items.
 2. The method of claim 1,wherein transmitting, by the mobile device, payment informationcomprises using the mobile device to transmit the payment informationover a near-field communications channel.
 3. The method of claim 1,wherein transmitting, by the mobile device, payment information isperformed using a digital wallet.
 4. The method of claim 1, wherein thepurchase information is received via a middle layer.
 5. The method ofclaim 1, further comprising receiving, by the mobile device, anindication of a suggested quantity of the commercially identical items,wherein selecting, by the mobile device, a quantity of the commerciallyidentical items comprises using the mobile device to accept thesuggested quantity.
 6. The method of claim 1, wherein further comprisingselecting, by the mobile device, the retail package from among aplurality of retail items purchased in the transaction.
 7. A methodcomprising: receiving a first text message, from a first subscribernumber, that identifies a provider, an item, and a quantity ofcommercially identical units within the item; receiving a second textmessage, from a second subscriber number, that indicates a requestrelating to the item; and transmitting, to the second subscriber number,a response to the request.
 8. The method of claim 7, wherein the item isa personal care item or a medication.
 9. The method of claim 7, whereinthe first text message comprises a product code that identifies theitem, and wherein the request relating to the item is a description ofat least one symptom.
 10. The method of claim 7, wherein the responseindicates an availability of at least one of the commercially identicalunits, or wherein the response comprises information identifying theprovider.
 11. A method comprising: receiving, from a mobile softwareapplication resident on a second mobile device, a request to purchase anitem; determining, based on a query of an inventory database, that theitem matches a plurality of commercially identical items purchased by auser of a first mobile device as part of a retail package that includesthe plurality of commercially identical items; providing, based on alocation of the second mobile device and a location of the first mobiledevice, an indication that the user of the first mobile device has theplurality of commercially identical items available for purchase;receiving, from a mobile wallet resident on a second mobile device, anindication of a purchase of one or more of the plurality of commerciallyidentical items from a user of the first mobile device; and updating,based the indication of the purchase, the inventory database to removethe purchased one or more of the plurality of commercially identicalitems from the quantity of one or more of the plurality of commerciallyidentical items.
 12. The method of claim 11, further comprising:receiving, from a mobile software application resident on the firstmobile device, information indicating a current location of the firstmobile device and an identifier of the mobile software application;selecting, based on the location of the mobile device, a point-of-sale(POS) system; transmitting, to the selected POS system, the identifierof the mobile software application resident on the first mobile device;receiving, from the selected POS system and the mobile softwareapplication resident on the first mobile device, an indication of theretail package that includes the plurality of commercially identicalitems; receiving, from the mobile software application resident on thefirst mobile device, an indication of a quantity of one or more of theplurality of commercially identical items; and updating, based on theidentifier of the mobile software application, the inventory databasewith the quantity of one or more of the plurality of commerciallyidentical items.
 13. The method of claim 12, the identifier includes alabel that identifies at least one among (A) a particular account of aloyalty program of a retailer associated with the POS system and (B) aparticular payment account.
 14. The method of claim 12, furthercomprising, in response to receiving the indication of the retailpackage, transmitting an indication of a suggested quantity of thecommercially identical items to the mobile software application residenton the first mobile device.
 15. The method of claim 12, furthercomprising, selecting one among a plurality of connection points that isassociated with the selected POS system.
 16. The method of claim 15,wherein the identifier is transmitted to the selected POS system via theselected connection point.
 17. The method of claim 15, wherein receivingthe indication of the retail package indicates completion of a purchasetransaction between the selected POS system and the first mobile device.18. The method of claim 15, wherein selecting one of a plurality ofconnection points that is associated with the selected POS systemfurther comprises: associating a location of each of a plurality of POSsystems with a respective connection point of the plurality ofconnection points; configuring each of the plurality of POS systems toconnect to the respective connection point of the plurality ofconnection points through a uniform resource locator (URL) associatedwith the respective connection point; and determining a connectionpoint, and an associated URL, of the plurality of connections pointshaving an associated location nearest the location of the first mobiledevice as the selected one of the plurality of connection points. 19.The method of claim 15, further comprising configuring each of theplurality of POS systems to connect to the respective connection pointof the plurality of connection points through a uniform resource locator(URL) associated with the respective connection point.
 20. The method ofclaim 15, wherein each of the plurality of connection points isconfigured to: receive the indication of the quantity of one or more ofthe plurality of commercially identical items into a buffer according toa respective format; verify that the indication of the quantity of oneor more of the plurality of commercially identical items is properlyformatted according to the respective format; and return an error codein response to a determination that the indication of the quantity ofone or more of the plurality of commercially identical items to therespective format.